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(54) File selection method 

(57) A file selectin method is 
provided for selecting a group of files 
from a tree-structured file directory 
stored on a computer. The selection 
method involves a user providing 
input to the computer to indicate the 
selection or deselection of specific 
files and sub-directories from a 
displayed listing of the file directory. 
In response to the user's 
selection/deselection inputs, the 
computer generates selection data 
with the selection/deselection of a 
subdirectory by the user being 
interpreted by the computer as the 
selection/deselection of all files 
entered therein and in any sub- 
directories except for files where a 
contrary lower-level 
selection/deselection input has been 
entered by the user. The computer 
provides visual feedback to the user 
by highlighting all selected files and 
subdirectories. 
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SPECIFICATION 

File selection method 

5 The present invention relates to a file selec- 
tion method for selecting a group of files from 
a tree-structured file directory stored on a 
computer. In particular, but not exclusively, the 
present invention relates to a method of se- 

10 lecting files for backup/restoration in a com- 
munity of independently-operable personal 
computers that are in communication with a 
central station; in this context,the term "per- 
sonal computer" is intended to mean an inde- 

15 pendently-operable computer work station ar- 
ranged to operate under a file-based operating 
system to store and retrieve working files 
from a non-volatile storage area. In selecting a 
group of files to undergo a particular operation 

20 (such as backup) from a tree-structured file 
directory, it is known to utilise wild card char- 
acters to construct a selection mask that fits 
all the desired files. It is also known to effect 
file selection by sub-directory. In both cases, 

25 the user will generally be required to type in 
his selection criteria which the computer then 
acts upon directly without first displaying a list 
of selected files for confirmation. 
Selection of group of files effected in the 

30 above manner is an unrefined process which 
does not enable a variety of files from differ- 
ent subdirectories to be quickly and easily se- 
lected. 

According to the present invention, there is 
35 provided a file selection method for selecting 
a group of files from a tree-structured file di- 
rectory stored on a computer, the computer 
having display means and user-operable input 
means for enabling the user to identify to the 
40 computer items of interest displayed on the 
display means; said method involving: 

a) — the presentation to the user of the di- 
rectory contents by means of said display 
means, 

45 b) — the user selection via said input means 
of files of interest to be selected or dese- 
lected, this user selection process being such 
as to permit the individual selection and dese- 
lection of both sub-directories and files, 

50 c) — the generation and storage by the com- 
puter in response to the operation of the input 
means, of selection data indicative of the se- 
lection statuses of the directory files and sub- 
directories, the selection/deselection of a sub- 

55 directory by the user being interpreted by the 
computer as the selection/deselection of all 
files entered therein and in any sub-directories 
except for files where a contrary, lower-level, 
file or sub-directory selection/deselection has 

60 been input by the user and stored by the 
computer in said selection data, and 

d) — the visual feedback to the user via said 
display means of the current selection status 
of each displayed file and sub-directory. 

65 Preferably, said selection data is stored in 



the form of a two-part list the first part of 
which is a list of directories individually selec- 
ted/deselected by the user together with an 
indication their selection statuses and the sec- 

70 ond part of which is a list of files individually 
selected/deselected by the user together with 
an indication of their selection statuses. 

The computer will generally utilise said se- 
lection list to identify the selected files making 

75 up said group of files by examining entry-by- 
entry the said tree-structured file directory, or 
the selected sub-directories thereof, and 
checking the selection status of each file en- 
tered therein by reference to said selection 

80 list. 

The file selection method of the invention 
can be advantageous used to select files for 
backup or restore between an independently- 
operable personal computer and a central sta- 
85 tion. 

BRIEF DESCRIPTION OF THE DRAWINGS 

A file selection method embodying the in- 
vention will now be described, by way of 
90 non-limiting example, in the context of a file 
backup facility for a community of personal 
computers, with reference to the accompany- 
ing drawings, in which: 
Figure 1 is a schematic representation of the 
95 personal computer community showing three 
personal computers each running a requestor 
program and linked to a central station running 
a server program; 
Figure 2 is a diagrammatic representation of 
100 a tree-structured directory such as used by 
the personal computers in Figure 1; 

Figure 3 is a diagram depicting the data 
structures making up a backup directory held 
by each personal computer; 
105 Figure 4 is a diagram illustrating the inter- 
active file selection method embodying the in- 
vention, the file selection process forming part 
of the requestor program; 
Figure 5 is a diagram depicting the data 
110 structures making up a file selection list gener- 
ated in response to user inputs in the Figure 4 
selection process 

Figure 6 is a flow chart of a requestor-pro- 
gram algorithm for changing in the file selec- 
1 1 5 tion list, the selection status of all files in a 
particular sub-directory; 

Figure 7 is a flow chart of a requestor-pro- 
gram algorithm for changing, in the file selec- 
tion list, the selection status of a particular 
120 file- 
Figure 8 is a flow chart of a requestor-pro- 
gram algorithm for interrogating the selection 
list to derive the selection status of a particu- 
lar file; 

125 Figure 9 is a flow chart illustrating the over- 
all operation of the requestor program in back- 
ing up a selection of files to the central sta- 
tion; 

Figure 10 is a flow chart of a requestor- 
130 program algorithm for checking the current/- 
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noncurrent status of files listed in the backup 
directory; 

Figure 1 1 is a flow chart illustrating the 
overall operation of the requestor program in 
5 restoring a selection of files from the central 
station; 

Figure 12 is a diagram illustrating the main 
processes, tasks and data structures of the 
server program run by the central station; 
10 Figure 13 is a flow chart illustrating the 
main functions of a scheduler process of the 
server program; 

Figure 14 is a flow chart illustrating the gen- 
eral form of a backup task and also of a 
1 5 restore task of the server program; 

Figure 15 is a flow chart outlining the main 
functions of a tape handler process of the 
server program; 

Figures 16A,B are flow charts of two rou- 
20 tines characterising a said backup task; and 

Figures 17A,B are flow charts of two rou- 
tines characterising a said restore task. 

DESCRIPTION OF THE PREFERRED EMBODI- 
25 MENT 

Shown in Figure 1 is a community of per- 
sonal computers (PCs) referenced PC1, PC2 
and PC3 which are linked to a central station 
10 via a local area network (LAN) 1 1 of any 

30 suitable form, including point-to-point and 
clustered configurations. 

The central station 10 comprises in the pre- 
sent example, a mini computer 12 and its as- 
sociated peripheral devices including a hard 

35 disc storage device 13 and a low-cost mass 
storage device 14 here constituted by a tape 
storage device. The mini computer operates 
under a multi-tasking operating system. 
As is illustrated in Figure 1 for PC3, each of 

40 the personal computers comprises a processor 
box 15, a disk storage device 16, an input 
device 17 (here shown as a keyboard, and a 
display unit 18. The disc device 16 may be 
one or more floppy disc drives and/or a hard 

45 disc unit; indeed, the device 16 may be a 
virtual disc device. In standard manner, the 
processor box 15 comprises a central pro- 
cessing unit 20 interfacing via a bus system 
23 with memory (namely, volatile RAM mem- 

50 ory 21, non volatile RAM memory 22 and the 
disc device 15) and also with the display unit 
18 via a display controller 24, with the key- 
board 17 via an I/O controller 25, and with 
the LAN 11 via a communications controller 

55 26. 

Each PC operates under a file-based operat- 
ing system that utilises a tree-structured file 
directory, for example, MS-DOS versions 2.0 
and above (MS-DOS is a trademark of Micro- 
60 Soft Corporation). Files, whether data or pro- 
gram, are stored by the disc device 16 and 
are called into RAM memory 21 by the oper- 
ating system as and when required. 
Although the disc device 16 constitutes a 



already discussed in the opening of the pre- 
sent specification, it is prudent to take regular 
backup copies of the files. To this end, and in 
accordance with the present invention, each 

70 PC is arranged under the control of a Reques- 
tor program, to backup files to and restore 
files from, the tape device 14 of the mini 
computer 12, the latter being controlled for 
this purpose by a continuously-available Server 

75 program. 

The Requestor program for each PC is held 
in the local disc device 16 and is arranged to 
run under the local operating system. This 
program gives the user the choice of functions 

80 shown on the screen of the display unit 18 in 
Figure 1, namely the choice of: 

1 . backup of selected files, 

2. backup of ail files included in a predeter- 
mined list, 

85 3. restoration of selected files. 

Both backup choices involve the generation 
of a selection list of files to be backed up, the 
first choice requiring the generation of this list 
each time the choice is selected while the 

90 second choice utilises a list previously gener- 
ated and stored (the pre-generation of this list 
being the fourth choice of the illustrated 
menu). 

As will be more fully described hereinafter 
95 the generation of the backup selection list in- 
volves the presentation to the user of the cur- 
rent contents of the file directory of the PC's 
operating system (referred to below as the OS 
directory). The user then makes his choice of 

100 files for backup from the presented files. 

In a similar manner, the restore choice in- 
volves the generation of a restore selection 
list by the user. In this case, however, the 
user makes his selection from the contents of 

105 a "backup" directory that records details of 
all files previously backed up from the PC con- 
cerned to the tape device 14 of the central 
station. In the present example, the mainte- 
nance of the backup directory is made the 

1 10 responsibility of each PC and the master copy 
of this directory is stored on the local disc 
device 16. However, a copy of the backup 
directory of each PC is also held centrally on 
the disc device 13 so that should a PC find 

1 1 5 that the local copy of the backup directory is 
missing or corrupted upon running the Re- 
questor program, then a fresh copy of the 
directory can be rapidly called up from the 
central station. As an alternative to the above 

120 described arrangement, the backup directories 
for all the PCs could be maintained by the 
mini computer 12 and information from these 
directories only passed to the PCs upon re- 
quest. 

125 The backup directory may list different ver- 
sions of the same file. Unless otherwise 
stated, the term 'versions' will be used herein 
to denote copies of the same file which differ 
in one or more snecified v/prsinn narameters 
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and date stamps, and access permissions. In 
order to distinguish between file versions, ver- 
sion data (size, time and date stamps, permis- 
sions) are held in the backup directory. Of 
5 course, only one version of a file listed in the 
backup directory can be 'current' in the sense 
that it is also listed in the current OS direc- 
tory; indeed, if a file has been deleted from 
the OS directory, then all backed up versions 

10 will be non-current. 

The backup directory is used not only to 
enable a user to make a restore selection, but 
also during backup to ensure that the same 
version of a file is not backed up twice at 

15 different times. 

Returning now to a general consideration of 
the backup process, once the backup selec- 
tion list has been generated or called up, a PC 
proceeds to establish communications with 

20 the central station 10 and to pass the se- 
lected files thereto in accordance with the re- 
levant communications protocol. The files are 
in fact passed to the station 10 in predeter- 
mined maximum block sizes(64K). Since 

25 generally the data rate over the LAN 1 1 will 
be much lower than that required to stream 
the tape device 14, the received file blocks 
are first buffered to the disc device 13 before 
being recorded en bloc to the tape device 14. 

30 The mini computer 12, under the control of 
the server program, is arranged to handle si- 
multaneously the backup requirements of a 
number of PCs, this being possible due to the 
multi-tasking nature of the mini-computer's op- 

35 erating system. In implementing this arrange- 
ment, the server program is arranged to inter- 
leave file blocks received from different PCs 
before streaming them to the tape device. 
Tape position information on each block is 

40 passed back to the relevant PC for storage in 
its backup directory together with data on the 
breakdown of each file into blocks. 

During restore, block information on the files 
selected for restore is retrieved from the bac- 

45 kup directory of a PC and used to request the 
mini computer to forward the appropriate file 
blocks. These blocks when received back at 
the PC are stored in the disc device 15 and 
the local OS directory is updated accordingly. 

50 Due to the fact that the files selected for 
restore may be scattered over the whole 
length of the tape media of the tape device 
14, it is preferable to arrange for the central 
station 10 to service only one restore request 

55 at a time. 

Having outlined the general operation of. the 
backup and restore facility of the Figure 1 PC 
community, a fuller description will now be 
given of the main novel functional compo- 

60 nents. However, before describing the backup 
and restore mode operations, the structures of 
the OS directory and backup directory will be 
considered so as to permit a proper under- 
standing of the system functioning. 



Directory Structures 

Figure 2 is a diagrammatic depiction of the 
tree-structured file directory of each PC oper- 
ating system. The first level or 'root' dir ctory 

70 lists a first group of files F1 and, in the pre- 
sent example, two sub-directories 01 and D2. 
In a similar manner, each, sub-directory lists 
one or more files and/or further sub-directo- 
ries; thus, the sub-directory D1 has files F2 1 

75 and two sub-directories D3 and D4. Fil s in 
different directories can have the same nam 
and to identify uniquely a file, it is necessary 
to specify not only the file name but also the 
drive and chain of directories leading to that 

80 file, this combination being generally termed 
the file pathname. The pathname of the files 
F6 in Figure 2 is thus: 

A:\D1\D4\D5 

85 

Typical data structures for implementing the 
OS directory are well known to persons 
skilled in the art and will not be described 
therein. 

90 Figure 3 illustrates the data structures used 
for the backup directory. The backup directory 
comprises four linked lists the first of which is 
a path list containing an entry 30 for each 
different pathname of the backed up files. 
95 The second backup directory list is a file list 
containing an entry 31 for each different 
backed-up file associated with a particular 
pathname. The file list entries associated with 
particular pathname are linked to each other 

100 and to the relevant path-list entry while the 
latter contains a pointer to the first associated 
file-list entry. 

The third backup directory list is a versions 
list containing an entry 32 for each backed-up 

105 version of a file entered in the file list. The 
versions-list entries associated with a particu- 
lar file are linked to each other and to the 
relevant file-list entry while the latter contains 
a pointer to the first associated versions-list 

110 entry. Each versions-list entry contains version 
identification data (file size, operating-system 
time and date stamps, permissions) and ver- 
sion status data (current or noncurrent). 
The fourth backup directory list is a block- 

115 map list containing for each entry 32 in the 
versions-list, one or more linked entries 33 
identifying the blocks into which the file ver- 
sion was divided when backed up. Each ver- 
sions-list entry contained a pointer to the first 

120 associated block-map list entry. Each block- 
map entry contains information identifying the 
file block and indicating the position of this 
block on the tape storage media of the device 
14. 

125 

File Selection Process 

A basic operation associated with all three 
main requestor program functions ('selective 
backup'; 'backup all'; 'restore') is the interac- 
130 tive generation of a selection list by the user. 
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As already noted, selection-list generation in- 
volves the display of the relevant directory 
(the OS directory in the case of the backup 
functions, and the backup directory in the 
5 case of restore). Thereafter, the user indicates 
which files are selected by using the PC input 
device 17 which, in the present example, is a 
keyboard. 

In the present embodiment, the user can 
10 effect selection by file and by (sub) directory 
with the selection of a directory being taken 
as selection of all files in that directory and all 
sub-directories. Furthermore, files and directo- 
ries can be specifically deselected so as to 
15 exclude these elements from a more general 
selection previously effected by choosing a 
higher level directory. The latest-in-time selec- 
tion/deselection operation overrides earlier 
choices. 

20 Figure 4 is a diagram illustrating the flow of 
control during the inter-active user-selection 
process. The first operation (block 40) is the 
display of the root directory of the OS or 
backup directory; the display of the root direc- 

25 tory involves the display of all the files and 
subdirectories in the root directory. Next, a 
user selection phase is entered (block 41) in 
which the user is presented with a number of 
choices any one of which he can select by 

30 pressing an appropriate one of the keyboard 
keys. 

A first choice, referenced 42 in Figure 4, 
provides for movement of the cursor around 
the display to pick out one of the files or 

35 directories presented. It will be appreciated 
that this cursor movement may be controlled 
by one or more keys as is considered appro- 
priate. Selection of the cursor movement 
choice 42 results in the PC effecting the rele- 

40 vant cursor movement (block 43) before re- 
entering the user-selection phase (block 41). 

A second choice, referenced 44, initiates 
the display (block 45) of a sub-directory 
picked out by the cursor before control is re- 

45 turned to the user-selection phase (block 41). 
A third choice 46 reverses this process in 
that it causes the parent directory of the cur- 
rently displayed directory to replace the latter 
on the screen display. Choices 42, 44 and 46 

50 together thus enable the contents of the 
whole of the OS or backup directory to be 
displayed starting from the root directory, 

A fourth choice, referenced 47, enables the 
whole of the currently-displayed directory to 

55 be selected, or if already selected, to be de- 
selected (the operation of the keyboard key 
relating to choice 47 thus being a toggling 
action). Selection of choice 47 results in the 
selection list being appropriately updated in a 

60 manner to be described, but here indicated by 
block 48. This is followed by the highlighting 
or dehighlighting of all the files and sub-direc- 
tories of the currently-displayed directory to 
indicate the selection or de-selection respec- 



47. Highlighting control is effected by block 
49. 

A fifth choice, referenced 50, offered by the 
user-selection block 41 is the selection/de-se- 

70 lection of cursor-picked files or sub-directories. 
Again, the operation of the relevant keyboard 
key acts as a toggle between the select and 
de-select functions. Selection of choice 50 re- 
sults in appropriate up-dating of the selection 

75 list (block 51) followed by appropriate up-dat- 
ing of the screen highlighting (block 52). 

Use of the user-selection choices 47 and 50 
enables any desired combination of files to be 
selected. Thus, for example, the following se- 

80 quence of operations enables the selection of 
all files with the exception of all-but-one of 
the files in a first level sub-directory: 

Choice 47 — toggles Root directory selec- 
tion/ deselection ; since initially the Root di- 

85 rectory is unselected, this directory becomes 
selected and all the files and sub-directories 
entered in the root directory are highlighted on 
the display. 
Choice 42 — the cursor is moved to pick out 

90 the sub-directory in which all files but one are 
to be deselected. 

Choice 50 — toggles selection/deselection 
for the picked sub-directory; since this direc- 
tory was previously selected, it now becomes 

95 deselected and is dehighiighted. 

Choice 44 — replaces the root directory dis- 
play with the contents of the sub-directory of 
interest 

Choice 42 — the cursor is moved to pick out 
100 the file to be selected 

Choice 50 — toggles selection/deselection of 
the picked file; since this file was previously 
deselected, it now becomes selected and is 
highlighted 

105 Once the desired files have been selected, 
the user exits the user-selection phase (block 
41) by selecting choice 53 labelled "proceed" 
in Figure 4. 
The foregoing description of the interactive 

110 selection-list generation process is complete 
so far as the selection of files from the OS 
directory for backup is concerned. However, 
the generation of a selection list from the bac- 
kup directory during a restore operation is 

1 15 somewhat more complicated due to the pos- 
sible presence of several versions of the same 
file. This complication is dealt with in the fol- 
lowing manner. First, for each directory dis- 
played from the main backup directory, the file 

120 names of all entries from the relevant portion 
of the file list (that is the portion linked to the 
appropriate pathlist entry) are presented on 
the screen. For each file, there is an indication 
of whether any of the versions of that file 

125 contained in the backup-directory versions list 
is a current version, that is, is a version cur- 
rently in the OS directory. If a file is picked 
and then selected via user choice 50, then the 
current version of that file will automatically 
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no current version exists, then user choice 50 
is ignored. In order to select a non-current 
version of a file, a user choice referenced 54 
must be selected to result in the display of all 
5 versions of a picked file (block 55). The user 
is now presented with three choices (see 
block 56) these being cursor movement 57, 
toggling (selection/ deselection) of the cursor- 
picked version 58, and returning to the rele- 

10 vant directory (choice 59). Only one version of 
the file may be selected at any one time. 

The selection status of a non-current file 
version is arranged to be unaffected by a sub- 
sequent change in selection status of its par- 

15 ent (or any ancestor) directory. 

Selection List 

In a preferred embodiment of the present 
invention, each selection list, rather than being 

20 a straight list of all the files to be backed up 
or restored, takes the form of a two-part list 
in order to minimize the storage requirements 
of the list. The form of data structures used 
for the selection list will now be described 

25 with reference to Figure 5 followed by a de- 
scription of the algorithms used to update and 
read the list (Figures 6, 7 and 8) 

The selection list comprises a pathlist cros- 
slinked with a filelist. Each entry 60 in the 

30 pathlist corresponds to a particular path and 
includes a pointer to any entries 61 in the 
filelist corresponding to files coming under 
that path. 

Each pathlist entry and each filelist entry has 
35 an "include/exclude" flag for indicating 
whether the corresponding files are to be 
taken as included or excluded from the selec- 
tion list. 

At the start of a selection list generation 

40 process, the selection filelist is empty and the 
pathlist contains a single entry corresponding 
to the root directory of the disc device 15. 
For selection list generation during selective 
backup or during restore, this single pathlist 

45 entry has its include/exclude flag marked for 
"exclude"; however for generation of the pre- 
determined selection list for use during the 
"backup all" mode, the include/exclude flag is 
preferably set to "include" and the root direc- 

50 tory is appropriately highlighted when put up 
on the display screen 18. 

Updating of the selection list in response to 
user selection choices 47 and 50 in Figure 4 
is effected on the basis that the selection sta- 

55 tus of the particular directory or file has been 
toggled — the updating algorithms used are 
such as to automatically change the selection 
status of the corresponding file or directory. 
There is thus no need to indicate to these 

60 updating algorithms the absolute selection sta- 
tus of a file or directory. 

Figure 6 is a flow chart of an algorithm for 
updating the selection list upon the selection 
status of a directory being toggled by the 

65 user. As can be seen, the first operation car- 



ried out by the updating algorithm is to search 
the selection pathlist to see if an entry already 
exists that corresponds to the directory con- 
cerned (block 62). If no entry is found in the 
70 pathlist (block 63), then a new entry is 

created for that directory (block 64) and this 
entry has its include/exclude flag set opposite 
to that of its nearest ancestor (block 65). 
Thus, if a sub-directory of an already included 
75 directory is toggled, then an entry is created 
for this sub-directory and the entry is marked 
for exclusion — this correctly reflects the user's 
choice since prior to being toggled, the sub- 
directory would have been displayed high- 
80 lighted so that the toggling of the sub-direc- 
tory must have been effected with a view to 
excluding the sub-directory from selection. 

Returning to block 63, if an entry is found 
in the pathlist for a toggled directory, then the 
85 basic consequential operation is to change the 
status of the include/exclude flag of the direc- 
tory entry. However, this operation will often 
result in redundant entries in the selection list 
as, for example, where several files have b en 
90 specifically excluded from a selected directory 
and then this latter is subsequently deselec- 
ted — i n this case, the filelist will contain re- 
dundant exclusion entries for the files of the 
de-selected directory. Since one of the main 
95 purposes of using the present selection list 
structure is to minimise the storage require- 
ments for the selection list, the toggling of 
any pre-existing entry will generally be accom- 
panied by housekeeping operations for remov- 
100 ing entries rendered redundant by this toggl- 
ing. In the present case, upon toggling of a 
directory for which an entry already exists in 
the pathlist, all file list entries corresponding 
to current files of the directory and of all its 
105 sub-directories are deleted (blocks 66 and 67) 
since these entries will now be redundant. 
Furthermore, if the filelist of any subdirectory 
to the toggled directory is empty, then the 
pathlist entry corresponding to this sub-direc- 
1 10 tory can also be removed (block 68). It should 
be noted that the filelist of the sub-directory 
will not necessary be empty as it may contain 
one or more entries corresponding to non-cur- 
rent file versions; as previously mentioned, the 
1 1 5 toggling of the selection status of a directory 
does not affect the selection status of non- 
current files. The reason why the sub-directory 
entry is left if a filelist entry exists that corre- 
sponds to a non-current file version, is that 
120 the algorithm to be described hereinafter with 
reference to Figure 8 for reading the selection 
list, requires the presence of a parent-directory 
entry as well as a file entry to properly iden- 
tify the status of a non-current file contained 
125 in the filelist. 

Following the deletion of unnecessary sub- 
directory entries in the pathlist, the include/ex- 
clude flag of the toggled directory is changed 
(block 69). If the status of this flag then cor- 
130 responds to that of the nearest ancestor di- 
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rectory entered in the pathlist (block 70), and 
if the filelist of the toggled directory is empty 
(block 71), then the pathlist entry of the tog- 
gled directory is also redundant and can be 
5 removed (block 72). 

Figure 7 is a flow chart of an algorithm for 
updating the selection list in response to the 
toggling of the selection status of a file (user 
choice 50 in Figure 4). The first step in this 

10 updating algorithm is to search the pathlist for 
an entry corresponding to the parent directory 
of the file (block 73). If no such entry is found 
(block 74) then one is created in the pathlist 
and its include/exclude flag is set the same as 

15 the nearest ancestor directory entry (block 
75). Thereafter, a filelist entry is created for 
the toggled file (block 76) and if the file is a 
current one (block 77) the include/exclude flag 
of the filelist entry is set opposite to that of 

20 the parent directory (block 78) as a current 
file will only have been toggled where its se- 
lection status is to be different to that of its 
parent directory. In the case of a non-current 
file, its include/exclude flag is set to "include" 

25 (block 79), the selection status of non-current 1 
files being independent of their parent directo- 
ries. 

Returning to block 74, if the initial pathlist 
search turns up an entry for the toggled file's 

30 parent directory, the filelist is then searched 
for an entry corresponding to the toggled file 
(block 80). If no such entry is found (block 
81), then one is created in the filelist and its 
include/exclude flag is set as described above 

35 (see block 76 to 79). However, if a filelist 

entry is found for the toggled file, this entry is 
removed (block 82). 

The updating algorithms described with re- 
spect to Figures 6 and 7 are those used by 

40 the inter-active user selection process to cre- 
ate a selection list. The algorithm shown in 
the flowchart of the Figure 8 is that used by 
the main Requestor program to interrogate a 
selection list to discover whether any particu- 

45 lar file has been selected or not. 

To check the selection status of a given file, 
the pathlist is first searched for an entry cor- 
responding to the file's parent directory (block 
84). If no such entry is found (block 85) then 

50 there is no need to search the filelist since the 
Figure 7 updating algorithm will always cause 
the creation of a parent directory entry when- 
ever a file list entry is generated. In the ab- 
sence of a parent directory entry in the path- 

55 list, the selection status of the file of interest 
is, of course, determined by the selection sta- 
tus of the nearest ancestor directory. Accord- 
ingly, the pathlist is next searched for the en- 
try corresponding to the nearest ancestor en- 

60 try (block 86) and the status of the inclu- 
de/exclude flag of this entry is returned as the 
selection status of the file of interest (block 
87). 

Where the initial pathlist search finds an en- 



of interest, the Figure 8 algorithm proceeds to 
search the filelist for an entry corresponding 
to the file (block 88). If a filelist entry is found 
(block 89) the status of the entry's include/ex- 

70 elude flag is returned as the selection status 
of the file (block 90). If an entry correspond- 
ing to the given file is not found, then the 
status of the include/exclude flag of the par- 
ent directory entry is returned as the selection 

75 status of the file of interest (block 91). 

It should be noted that when using the al- 
gorithms of Figures 6 and 7 in relation to a 
selection list for backup, the checking of the 
files identity can be based solely on the file's 

80 name since the only file versions being dealt 
with are current ones. However, in the case of 
a selection list created for restore, the check- 
ing of a file's identity must be based on a 
check not only of the file's name but also of 

85 its version data. 

Having described the inter-active user selec- 
tion process and the updating and interroga- 
tion of the resultant selection lists, a descrip- 
tion will now be given of the backup and re- 

90 store function themselves. 

Backup Functions 

Referring to Figure 9, if the user chooses 
the "selective backup" function from the main 
95 menu presented by the Requestor program, 
then a backup selection list is first produced 
in the manner already described with reference 
to Figure 4; this process is indicated in Figure 
9 by block 92. Where the "backup all" func- 
100 tion is selected by the user then a previously 
created selection list is fetched from store 
(block 93). 

In either case, once a selection list is avail- 
able, the Requestor program opens up the link 

105 via LAN 11 with the central station. 10 and 

requests the services of the latter for effecting 
a backup operation (block 94). The Server 
program will either grant this request or in 
certain circumstances (such as where a re- 

110 quest for restore is already being serviced) 
ask the requesting PC to wait for a predeter- 
mined delay time before requesting again 
(block 95). Where the Requestor program is 
asked to wait, it will close the link with the 

115 central station (block 96) and wait for the 

specified period of time (block 97) before rein- 
itiating the backup request. 

Once the Server program has indicated to a 
requesting PC that the central station's backup 

120 facilities are available, the PC Requestor pro- 
gram proceeds to identify the files to be 
backed up. 

It will be appreciated from the form of the 
selection list that this list in itself does not 

125 contain adequate information to identify all 
files to be backed up. Instead, the selection 
list must be used in conjunction with the cur- 
rent OS directory to identify the files for bac- 
kup. The file idenfication process involves 
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whether each file found is encompassed by 
the current backup selection list. Algorithms 
for walking through the OS directory to find 
each file in turn will be apparent to persons 
5 skilled in the art and will therefore not be 
elaborated herein. However, it should be noted 
that so far as the main Requestor program is 
concerned (Figure 9) this walking of the OS 
directory is only required to be carried out 

10 one step at a time and that it is therefore 
necessary to maintain a pointer indicating the 
progress of this walkthrough. 

The initial step in identifying the files to be 
backed up is therefore to initialise an OS 

15 search pointer to the start of the OS directory 
(block 98). Thereafter, the walkthrough of the 
OS directory is commenced (block 99) and 
when a file is found the search pointer is up- 
dated and the identity of the file is extracted 

20 (blocks 99,100). 

The backup selection list is then interro- 
gated in the mann previously described to 
check whether the file found by walking the 
OS directory is one selected for backup (block 

25 101). If the file is not to be backed up, walk- 
ing through of the OS directory continues 
from the new pointer position. 

If, however, the file is found to be one se- 
lected for backup, a check is next made to 

30 see if that particular file version has already 
been backed up (block 102). This check is 
made by searching the backup directory and, 
again, appropriate search algorithms will be 
apparent to persons skilled in the art. If the 

35 current file version has already been backed 
up, then the walkthough of the OS directory is 
continued. Where the file version is not al- 
ready backed up, the Requestor program 
creates a new entry for the file version in the 

40 backup directory (block 103) before proceed- 
ing to split the file into blocks and transmit 
them over the LAN 1 1 to the central station 
10 (block 104). The creation of a new backup 
directory entry will always involve the creation 

45 of a new entry in the versions list (see Figure 
3) and may also involve new entries in the 
filelist and pathlist. The splitting of the file into 
blocks results in appropriate entries being gen- 
erated in the block map list. 

50 The correct receipt of the file blocks by the 
central station 10 is, of course, checked for in 
accordance with the communications protocol 
being used. However, in addition, a check is 
made that the transmitted file blocks have 

55 been recorded on the storage media of the 
tape device 14. This check may be imple- 
mented by arranging for an appropriate mes- 
sage to be passed by the Server program to 
the requesting PC following a successful read- 

60 after-write operation on a file block. The Re- 
questor program of the PC checks that mes- 
sages have been received on all transmitted 
file blocks by maintaining a temporary tran- 
sport acknowledgement list linked to the block 

65 map list. The messages passed back from the 



Server program to the Requestor program also 
contain data mapping block identity to relative 
position on the tape media, this information 
being stored in the relevant block map list 
70 entry for each file. 

After all file blocks have been acknowledged 
as having been correctly, recorded on the tape 
media, the walkthrough of the OS dir ctory is 
continued to find the next file. If one or more 
75 file blocks are not acknowledged as having 
been correctly recorded on the tape media 
after a predetermined timeout, then an alarm 
is raised (see blocks 105 and 106). 
In due course, the walkthrough of the OS 
80 directory will be complete. Thereafter, an end- 
of-data (EOD) messsage is transmitted and the 
backup directory is updated in respect of 
which file versions listed therein are current 
(see blocks (135 and 107). Figure 10 shows 
85 in flow-diagram form a suitable algorithm for 
effecting this file-version status check. As can 
be seen, this check is carried out by walking 
through the backup directory and stopping at 
each file version marked as current to see if 
90 that file version is still listed in the OS direc- 
tory. The process of walking through the bac- 
kup directory is controlled by a search pointer 
initialised to the start of the backup directory 
(block 110). Upon a file version marked cur- 
95 rent being found, (blocks 111 and 112) the 
search pointer is updated and then a check is 
made as to whether that file version is still 
present in the OS directory(1 13). If the file 
version is present in the OS directory, the 
100 process of walking through the backup direc- 
tory continues from the position indicated by 
the search pointer. However, if the file version 
is no longer contained in the OS directory, the 
status of that file version is marked as non- 
105 current in the versions list of the backup di- 
rectory (block 114). 

After the updating of the file-version status 
information in the backup directory, the Re- 
questor program proceeds to transmit the up- 
1 10 dated backup directory to the central station 
10 (block 108) before sending an end-of- 
transmission (EOT) message to initiate closing 
of the link (block 109). The updated backup 
directory is stored in the central station on the 
1 15 disc device 13. 

For reasons which will become clear below, 
it is desirable to enable the Server program to 
abort a backup operation. This can be 
achieved by substituting an abort message for 
120 a file block acknowledgement normally 

transmitted during execution of block 104; 
upon detecting such an abort message, the 
Requestor program can simply be arranged to 
close the link and terminate the current bac- 
125 kup session, the whole backup operation be- 
ing automatically re-initiated from block 94 
after a predetermined delay. 

The Restore Function 
130 Selection of the restore choice from the 
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opening menu presented by the Requestor 
program results in the sequence of operation 
illustrated in Figure 11. 
The first operation is the inter-active genera- 
5 tion of the restore selection list (block 115) in 
the manner already described with reference 
to Figure 4. Thereafter, the Requestor program 
opens the link with the central station 10 and 
passes a request thereto asking for the facili- 

10 ties of the central station to be made available 
for restoring one or more files to the request- 
ing PC (block 116). As already noted, to facili- 
tate access to the serial storage device consti- 
tuted by the tape device 14, only one restore 

15 operation is allowed to be in progress at any 
one time and this operation cannot be ef- 
fected at the same time as a backup oper- 
ation. The Server program is therefore ar- 
ranged to grant a restore request only if no 

20 other restore or backup process is in oper- 
ation. If a restore or backup operation is run- 
ning, then the Server program asks the re- 
questing PC to wait (block 117) and, in this 
case, the Requestor program will close the 

25 link with the central station (block 118) and 
waits a pre-determined time before re-opening 
the link and re-submitting its restore request 
to the central station (block 1 19). 

In due course, the restore request will be 

30 granted. Thereupon, the Requestor program 
will identify the files to be restored by walking 
the backup directory and checking each entry 
against the restore selection list. The step-by- 
step walkthrough of the backup directory re- 

35 quires the maintenance of a search pointer 
which is initialised to the start of the directory 
and updated each time a file is found and the 
walkthrough interrupted to check whether that 
file is in the restore selection list (see blocks 

40 120, 121 and 122). Suitable algorithms for 
searching the backup directory on a file ver- 
sion by file version basis will be apparent to 
persons skilled in the art. 

Each file version found in the backup direc- 

45 tory is checked against the selection list in the 
manner already described with reference to 
Figure 8 (block 123, Figure 1 1). If the file is 
not indicated as being selected upon inspec- 
tion of the list, the walkthrough of the backup 

50 directory is continued. 

Upon identification of a file version selected 
for restore, the Requestor program first 
checks to see whether the existing OS direc- 
tory is already structured with the path rele- 

55 vant to that file (block 124). If no such path 
exists, then the appropriate directory entries 
are created in the OS directory using the oper- 
ating system functions which, in the case of 
MS-DOS are accessible through interrupt 21H 

60 (see block 125 in Figure 11). 

If the path of the file to be restored already 
exists in the OS directory, then a check is 
next made as to whether the OS directory 
contains an entry corresponding to that file 



Where no file entry is pre-existing, then 
both in the case of a pre-existing path and in 
the case of a newly created path, a file entry 
is created in the OS directory corresponding 
70 to the file to be restored (block 127). There- 
after, the Requestor program utilises the data 
stored in the block map list of the backup 
directory to request the central station to for- 
ward the appropriate file blocks making up file 
75 to be restored (block 128). As will be ex- 
plained hereinafter, the Server program does 
not respond to the file-block requests immedi- 
ately but awaits the receipt of an EOD mes- 
sage before doing so. Once all the relevant 
80 blocks have been requested, the Requestor 
program continues its walk through the bac- 
kup directory. 

Returning to block 126, if the search of the 
OS directory shows that the file to be re- 
85 stored is already entered in the directory (al- 
beit a different version of the file), the Re- 
questor program prompts the user to confirm 
that he wishes the existing entry to be over- 
written by one corresponding to the file ver- 
90 sion previously indicated as required for resto- 
ration (block 129). If the user indicates that he 
wishes the restore operation to continue 
(block 130), then the previous OS directory 
entry is overwritten (block 131) and the Re- 
95 questor program proceeds to request the ap- 
propriate file blocks from central station 10. 
On the other hand, where the user indicates 
that he no longer wishes the restoration of 
the selected file to continue, the Requestor 

100 program returns to its walk through of the 
backup directory. 

In due course, the walkthrough of the bac- 
kup directory will be completed whereupon 
the Requestor program transmits an EOD mes- 

105 sage the effect of which is to trigger the Ser- 
ver program to retrieve and forward the re- 
quested file blocks (see blocks 132,133). 
After all requested file blocks have been re- 
ceived, the Requestor program send an EOT 

1 10 messgage to initiate closing of the link with 
the central station 10 (blockU34). 

The process of walking through the backup 
directory can generally be considerably shor- 
tened due to the fact that files selected for 

1 15 restore are normally to be found in only one 
or two sub-directories. Rather than walking 
the whole backup directory, the selection list 
can be examined to ascertain which directories 
are going to be relevant and then only these 

120 directories are walked. 

A second type of restore request may be 
made by the Requestor program itself, this 
being a request for restoration of the appropri- 
ate backup directory; such a request is made 

125 by the Requestor program if upon initialisation 
the latter discovers that the directory is not 
present at the PC. A directory restore request 
will generally be granted immediately by the 
Server, the restore operation itself being ter- 
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The Server Program 

Having described the operation of the re- 
questor program run by each PC, the function- 
5 ing of the server program at the central sta- 
tion 10 will now be explained. 

As already noted, the server program is de- 
signed to run under a multi-tasking operating 
system. The program comprises three main 

10 processes which run concurrently on the com- 
puter 12; as show in Figure 12, these three 
processes are respectively a monitor process 
140, a scheduler process 141 and a tape 
handler process 142. 

15 Whenever a PC makes a request to the cen- 
tral station 10 to backup or restore one or 
more files, the PC first establishes a virtual 
circuit with the computer 12 and directs its 
request to the monitor process 140. This pro- 

20 cess 140 is arranged to create for each re- 
questing PC a respective task 143 which will 
be either a backup or restore task depending 
on the nature of the request. This task 143 
then deals with all further communication be- 

25 tween the server program and the particular 
PC concerned. On termination of a request 
due to its successful execution or otherwise, 
the task closes down the virtual circuit with 
the associated PC and then dies. At anyone 

30 time, several tasks 143 may be in existence. 
As will be more fully explained hereinafter, 
upon creation, each task 143 checks in with 
the scheduler 141 which determines whether 
the request from the corresponding PC can be 

35 dealt with straight away or must be delayed. 
In the present embodiment, the scheduler is 
arranged such that a backup request cannot 
be granted whenever a previously-granted re- 
store request is still being serviced though a 

40 restore request will cause any current backup 
tasks to be cancelled; furthermore, only one 
restore request may be serviced at a time 
though several backup requests can be ser- 
viced together. 

45 Upon the scheduler granting a request, the 
relevant task 143 then proceeds to interface 
with the tape handler 142 to transfer file 
blocks in the appropriate direction between 
the requesting PC and the tape device 14. 

50 Communication between the task 143 and the 
tape handler process 142 is by way of: 

- Request messages passed from the task 
143 to the handler in response to inputs re- 
ceived from the corresponding PC; the main 

55 types of request messages are for the backup 
of a file block just received from the PC (a 
backup request message) and for the restore 
of a file block requested by the PC (a restore 
request message). 

60 - Acknowledgement messages passed from 
the tape handler to the task to acknowledge 
the completion of a requested operation. 
Again, the main types of acknowledgement 
are backup acknowledgements output when a 

65 file block has been stored on tape, and re- 



store acknowledgements output when a re- 
quested block has been read from the tape. 

In the case of a backup operation, the task 
143, as well as interfacing with the tape 

70 handler 142, also takes care of buffering file 
blocks to the disc device 13 prior to these 
blocks being streamed to the tape device 14 
by the tape handler 142. The disc device 13 
is also used to store the backup directories 

75 relating to each PC. 

As will become clear below, an important 
data structure in the file-block transfer oper- 
ation is a block table 144 which is a list of 
file blocks to be transferred to or from the 

80 tape device 14. Each active task has a version 
144 A of this table for the blocks it is respon- 
sible for, while the tape handler has a single 
table 144B which deals with all blocks that 
have been passed to it. 

85 Another important data structure is a user 
status list 143 associated with the tape 
handler 142. This list 145 records for each 
user PC whether that PC is in one of the 
following four states: 

90 Inactive 
Active 
Complete 
Acknowledged 

The last three states correspond to a user 
95 PC being at different stages in the process of 
transferring data to/from the central station 
10. Each user entry in the user status list also 
contains other information such as the number 
of outstanding blocks waiting to be trans- 
100 f erred to or from the tape device 14. A more 
detailed explanation of the operation of the 
server program will now be given starting 
with a description of the scheduler process 
141. 

105 

The Scheduler 

As already noted, the function of the sche- 
duler is to decide whether a newly-created 
task 143 should be allowed to run immedi- 

110 ately or delayed for a predetermined period (in 
which case the task is, in practice, terminated 
and recreated by the monitor 140 in response 
to the relevant PC repeating its request after 
the predetermined delay). 

1 15 The scheduler maintains a list of currently 
active tasks previously allowed to run by the 
scheduler. 

Upon a newly-created task 143 checking in 
with the scheduler, the latter checks to see if 

120 a restore task is already current since if this is 
the case, no further tasks will be allowed and 
the scheduler will return a pre-set delay time, 
for example, 15 minutes, via the new task to 
the requester PC (see blocks 150, 154, 159 

125 in Figure 13). Where a restore task is not 

currently running, the scheduler next ascertains 
whether the checking-in task is a backup task 
or a restore task (block 155). In the latter 
case, the new task will have priority over any 

130 current task (as such tasks will be backup 
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tasks), so that the scheduler proceeds to 
abort all current tasks, grant the restore task 
request and update the current task list 
(blocks 156, 157, 158). On the other hand, if 
5 the checking-in task is a backup task, this will 
be allowed to run alongside the existing cur- 
rent backup tasks provided no more than a 
predetermined maximum number (for example, 
four) of such tasks are simultaneously current 

10 (block 153); if this condition is not fulfilled, 
the scheduler does not allow the task to run 
and returns a delay time. 

When a task has been completed, it checks 
out with the scheduler which then removes 

1 5 the task from the list of tasks being run (block 
160). 

In order to facilitate the restoration of a PC 
backup directory, the scheduler can be ar- 
ranged to grant such requests immediately 
20 (this facility is not shown in Figure 14). This 
does not cause currently active Backup tasks 
to be cancelled. 

General Form of Backup and Restore Tasks 
25 The general form of the task 143 created 
by the monitor process 140 is the same for 
backup and restore; Figure 14 is a flow chart 
representation of this general form. 
Following task creation (block 161) the task 
30 receives various necessary items of data from 
the monitor process and the associated re- 
questor PC (block 162); this data includes the 
messaging addresses for the scheduler and 
tape-handler processes 141, 142 and the re- 
35 turn address of the requestor PC. Thereafter, 
the task checks in the scheduler process 141 
by sending an appropriate message to the 
process (block 163). 
As already described with reference to Fig- 
AO ure 13, the scheduler will either allow the task 
to proceed or will return a delay time. If a 
delay time is returned (tested for in block 
164), the task proceeds to report this delay 
back to the associated PC (block 165); there- 
45 after, the task closes the virtual circuit link 
with the PC (block 166), checks out with the 
scheduler (block 167) and then dies (block 
168). 

If the scheduler allows the task to proceed 
50 immediately, the task informs the tape-handler 
by passing an access request message to the 
handler (block 169); the acknowledgement re- 
turned from the tape handler is then passed 
back by the task to the requesting PC (block 
55 170) to indicate to the latter that it may pro- 
ceed with the requested backup or restore 
function. 

The task thereafter enters a cyclic phase in 
which it receives messages from the request- 
60 ing PC and the tape handler (block 171), de- 
termines the origins of these messages (block 
172) and then executes an appropriate routine 
in dependence on the message origin (routine 
1 for messages from the requestor PC and 



The task continues to receive messages and 
execute the appropriate routine until it receives 
an EOT acknowledgement from the tape- 
handler (block 173) as a consequence of the 

70 requestor PC having completed the desired 
function and sent an end-of-transmission mes- 
sage via the task to the handler which has 
thereupon acknowledged the receipt of the 
EOT message. Upon detection of the EOT ac- 

75 knowledgement, the task proceeds to close 
the link, check out with the scheduler and die 
(block 166 to 168). 

The nature of routines 1 and 2 does, of 
course, depend on whether the task is a bac- 

80 kup or restore task. Routines 1 and 2 will be 
described in greater detail hereinafter following 
a general outline of the tape-handler process 
142. 

The backup task in fact includes one addi- 
85 tional branch not shown in Figure 14, permit- 
ting the scheduler process to abort a current 
backup task. This branch originates at a fur- 
ther exit from block 172 and is taken upon an 
abort message being received by the schedu- 
90 ler; the branch controls the passing of an 

abort message to the corresponding requester 
PC and to the tape-handler, after which blocks 
166 to 168 are executed. 

95 The Tape-Handler 

The basic operation of the tape-handler pro- 
cess is to service request messages passed 
to it by the currently task or tasks 143. Five 
separate types of request messages can be 
100 distinguished, these being: 

1) access request messages from newly al- 
lowed tasks whereby the the associated re- 
questing PC is noted as active by the tape- 
handler; 

105 2) backup request messages from backup 
tasks requesting the tape-handler to store to 
tape file blocks received by the task from 
their associated PCs these requests may not 
be complied with immediately by the tape- 

1 10 handler as it may wait for sufficient file blocks 
to be present to facilitate streaming of the 
tape; 

3) restore request messages from a cur- 
rently running restore task requesting the 

1 15 tape-handler to read off particular file blocks 
from the tape device and pass them back to 
the appropriate PC; 

4) directory request messages from tasks 
wishing to backup or restore PC backup direc- 

120 tories stored on the disc device 13; 

5) abort request messages from a backup 
task, requesting the tape-handler to note that 
the task is being aborted. 

The tape-handler process can reside in any 
125 one of the three main modes namely a no- 
operation mode (NOP mode), a backup mode 
in which the handler is dealing with one or 
more backup requests only, and a restore 
mode in which the handler is dealing with sin- 
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the tape-handler depends on the type of task 
currently being allowed to run by the schedu- 
ler process; when no task is current the tape- 
handler is in the NOP mode. 
5 Referring now to the tape-handler flow chart 
shown in Figure 15, the cycle of operation of 
the tape-handler starts with the latter reading 
in a message sent to it from a task (block 
175). After determining the message type 

10 (block 176), the tape-handler proceeds to pro- 
cess the message accordingly. 

Starting from the situation where the tape- 
handler is in its NOP mode, the next message 
that it will receive is an access request mes- 

15 sage from a backup or restore task. Having 
determined the message type, the tape- 
handler resets its mode to correspond to that 
of the originating task (backup or restore), an 
indication of the task type being contained in 

20 the access request message (block 177). In 
the case of an access request being made by 
a backup task when similar tasks are already 
running, the latest access request will already 
find the tape-handler in the appropriate mode 

25 so that the mode-setting operation is skipped 
by carrying out an appropriate test (block 
178). Thereafter, the tape handler updates the 
user status list 145 by noting that the user 
PC initiating the current task is "active" (block 

30 179). Once the user list has been updated, 
the tape-handler acknowledges the access re- 
quest by passing back a message to the task 
concerned (block 180); as previously noted, 
this acknowledgement is forwarded by the 

35 task to the requesting user PC (see block 
170, Figure 14). 

After a task has signed on with the tape- 
handler by means of an access request mes- 
sage, it proceeds to send backup or restore 

40 request messages to the tape-handler and re- 
ceives appropriate acknowledgements there- 
from until the desired function of backup or 
restore is complete. A detailed description of 
the processing of backup and restore request 

45 messages by the tape-handler will be given 
hereinafter when describing the routines 1 and 
2 that are at the heart of the backup and 
restore tasks. 
The tape handler responds to a directory 

50 request message either by backing up to, or 
restoring from, an allocated disc file, the bac- 
kup directory of the PC associated with the 
task sending the request message (block 233, 
181). 

55 Finally, on receipt of an abort message, the 
tape handler will set the status of the corre- 
sponding user to "inactive", remove any rele- 
vant entries from the tape-handler block table 
144B, and, if all users are then "inactive", 

60 reset its mode to NOP (see blocks 230 to 
232). 

The Backup Operation 
The inter-action of a backup task and the 
65 tape-handler process in carrying out the bac- 



kup operation to the tape device 14 will now 
be described with reference to the tape- 
handler flowchart Figure 15 and to the 
flowcharts of Figures 16A and 16B which re- 

70 spectively illustrate the form of , the routines 1 
and 2 in the back up task. 

It will be assumed that a PC requiring bac- 
kup has made an appropriate request to the 
central station and that a corresponding bac- 

75 kup task has been created by the monitor 
process 140; it will also be assumed this task 
has been allowed to proceed by the scheduler 
process 141 and that the task has signed on 
with the tape-handler process 142 and re- 

80 turned the acknowledgement received there- 
from back to the requesting PC. The backup 
task is therefore at the position of block 171 
in the Figure 14 task flowchart and is ready 
to receive messages from the requesting user 

85 PC and the tape-handler process; the tape- 
handler itself is in its backup mode and ready 
to receive messages from the backup task. 

The first message received by the backup 
task will be from the associated PC and will 

90 include a file block to be backed up to tape. 
On receipt of this message, the backup task 
executes backup routine 1 shown in Figure 
16A. This routine first tests the contents of 
the message received from the PC (block 182) 

95 to ascertain whether the message contains file 
data to be backed up to the tape device, bac- 
kup directory data to be stored on the disc 
device, or an end-of-data (EOD) or end-of-tran- 
mission (EOT) signal. As already noted, the 
100 first message received from the PC will con- 
tain file data and the backup routine 1 pro- 
ceeds by spooling this data to a temporary 
disc file (block 183). Having spooled the file 
data to disc, the routine updates the task 
105 block table 144A with an entry identifying the 
file block and its origin (block 184). There- 
after, the routine notifies the tape-handler pro- 
cess that it has a file block waiting to be 
backed up to tape, this notification being by 
1 10 way of a backup request message (block 
185). The backup task then exits routine 1 
and waits to receive another message. 

The tape-handler, having received the bac- 
kup request message from the backup routine 

115 1. first tests to see whether the message is 
informing it of the presence of a file block to 
be backed up or whether the message con- 
tains an EOD or EOT indication in respect of 
the current backup operation (block 186). Hav- 

120 ing determined in the present case that the 
backup request message relates to the pres- 
ence of a file block to be backed up, the 
tape-handler process first notes the existence 
of the file block awaiting backup by both mak- 

125 ing an entry in the block table 144B and up- 
dating the blocks outstanding field for the ap- 
propriate user entry in the user status list 145 
(see block 187). Thereafter, the tape-handler 
checks to see whether the aggregate size of 

130 the file blocks temporarily held on the disc 
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device is sufficient to enable streaming of the 
tape device 14 (block 188). If this is not the 
case, the tape-handler takes no immediate fur- 
ther action and awaits receipt of the next 
5 message. On the other hand, if the aggregate 
size of outstanding blocks is such as to ena- 
ble the tape device to be streamed, then the 
tape-handler initiates transfer of the corre- 
sponding file blocks from the disc device to 

10 the tape device (see block 189), the neces- 
sary information on the blocks being available 
to the tape-handler in the block table 144B. 
As each file block is written to tape a read- 
after-write check is carried out and, assuming 

1 5 that the results of this check are satisfactory, 
the tape then passes an acknowledgement 
message back to the appropriate backup task 
and updates the block table 144B and the 
blocks-outstanding information in the appropri- 

20 ate user list entry. 

It should be noted that since more than one 
backup task may be running, the question of 
whether there is sufficient file data to stream 
the tape device will not necessarily depend 

25 upon whether sufficient data has been re- 
ceived from any particular PC. Furthermore, 
the updating of the user status list and the 
destination of acknowledgment messages will 
depend upon the user (requesting PC) associ- 

30 ated with each file block backed up to tape. 
The flowchart blocks 190 and 191 shown 
as following the write-to-tape block 1 89 in 
Figure 15 relate to happenings that occur at 
the end of a backup operation and will be 

35 described later on; for the moment, it will be 
assumed that they do not apply to the backup 
operation under consideration so that after 
carrying out the functions indicated in block 
189 the tape-handler returns to await the re- 

40 ceipt of the next message. 

Returning now to the backup task, the next 
message received by this task will generally 
either be a further file-block-containing mes- 
sage from the requesting PC or, if the tape- 

45 handler decided that it could stream the tape 
device, an acknowledgement message from 
the tape-handler indicating that the previously- 
received file block has been successfully writ- 
ten to tape. In this latter case, the backup 

50 task will proceed to execute routine 2 illus- 
trated in Figure 16B. This routine involves an 
initial test of the acknowledgment message to 
see whether it is an acknowledgement of file 
block data or of an EOD/EOT signal (block 

55 192). Where a fileblock has been acknow- 
ledged, the routine looks after passing on the 
acknowledgement back to the requesting PC 
(block 193), deleting the block from the tem- 
porary disc file where it was stored on receipt 

60 (block 194), and updating of the task block 
table 144A by removal of the corresponding 
entry (block 195). On exiting routine 2, the 
backup task returns to block 171 to await 
receipt of the next message. 
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message will be received from the requesting 
PC containing fileblock data to be backed up. 
Such a message is dealt with in the manner 
already described by the backup task calling 

70 routine 1 to notify the tape-handler of the 
presence of the newly received file block. Fur- 
thermore, the tape-handler will deal with the 
new backup request in the manner already de- 
scribed, only returning acknolwedgements 

75 when the file block is written to tape and 
checked. 

When the requesting PC has transmitted all 
the fileblocks intended, it sends an EOD mes- 
sage. This message is identified by backup 
80 routine 1 and passed to the tapehandler in a 
backup request message (see block 196 in 
Figure 16 A). On detecting the presence of an 
EOD signal in the backup request message, 
the tape-handler sets the status of the corre- 
85 sponding user PC as "complete" in the user 
status list 145 — that is, the PC has completed 
its transmission of file data (block 197 in Fig- 
ure 15). However, this status does not mean 
that the backup of file data is complete since 
90 there may still be file blocks temporarily 

stored on disc waiting to be written to tape. 
If a test shows that this is not the case (block 
198) then the EOD signal is acknowledged 
and the user status in the user status list 145 
95 is set to "acknowledged" (block 191). On the 
other hand, if there are still file blocks waiting 
to be written to tape, then a check is made 
(block 191) as to whether there are any other 
user PCs active since, if not, this means that 

100 the critical size for streaming will not be 

reached in the near future and the backup op- 
eration could effectively be suspended until 
some indeterminate time when another backup 
task is initiated. To avoid this situation, if 

105 there are no other active users, the tape 

handler writes any outstanding blocks to tape 
and acknowledges the blocks in the usual 
way. When the last block has been written to 
tape and acknowledged the status of the user 

110 is changed from "complete" to "acknow- 
ledged" and an EOD acknowledgement sent 
(blocks 190, 191). If, however, the test car- 
ried out in block 199 shows that there are 
users still active, then the writing of outstand- 

115 ing blocks is deferred as it is quite likely that 
a streamable mass will be shortly achieved; of 
course, even in this deferred situation once all 
outstanding blocks of a "completed" user 
have been written to tape, that user's status 

120 is set to "acknowledged". 

On receipt of an EOD acknowledgement 
message, the backup task relays this acknow- 
ledgement to the corresponding PC (see block 
200 of backup routine 2 in Figure 16B). 

125 It should be noted that the file block ac- 
knowledgements passed back by the backup 
routine 2 to the corresponding PC contain 
tape location information for the corresponding 
file block and this information is stored by the 
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kup directory. 

After the requesting PC has transmitted all 
the file data to be backed up and followed it 
with an EOD message, the PC next sends up 
5 the updated backup directory for storage by 
the disc device 13. Upon the backup task as- 
certaining that the contents of a message 
from its associated PC contains backup direc- 
tory data (see block 182 in Figure 16A), the 
10 task after having first spooled the data to a 
temporary disc file, sends a directory request 
to the tape-handler requesting the latter to 
backup the directory to disc (blocks 201,202). 
The tape-handler then proceeds to write the 
15 directory data to a predetermined disc file as- 
sociated with the requesting PC overwriting 
any existing information in that file (block 
233). The tape handler then passes an ac- 
knowledgement to the backup task which for- 
20 wards this acknowledgement to the PC (block 
203, Fig. 16B). 

Finally, the requesting PC will transmit an 
EOT message. This message is passed by 
backup routine 1 to the tape-handler as a con- 
25 sequence of which the status of the corre- 
sponding user PC is set as "inactive" in the 
user status list (see block 205 in Figure 15). 
The EOT message is then acknowledged by 
the tape handler (block 206) and if no non- 
30 inactive users remain, the tape-handler reverts 
to its NOP mode (blocks 207 and 208). After 
passing back the EOT acknowledgement from 
the tape handler to the requesting PC, the 
backup task closes the link with the PC and 
35 checks out in the manner previously de- 
scribed. 

The Restore Operation 
The inter-action of the restore task and the 

40 tape-handler process in carrying out a restore 
operation will now be described with refer- 
ence to the tape-handler flowchart of Figure 
15 and the flowcharts of Figures 17A and 
17B which respectively relate to the restore 

45 routines 1 and 2. As with the description of 
the backup operation, the following description 
of the restore operation will assume that a 
restore task has already been created in re- 
sponse to a request from a PC and that this 

50 task, after having been allowed and having 
checked in with the tape handler, is awaiting 
receipt of a message from the requesting PC. 

The PC concerned may request either the 
restoration of one or more files by making 

55 requests for the constituent file-blocks or, al- 
ternatively, may request the restoration of the 
backup directory associated with the PC and 
stored on the disc device 13. 
Considering first the case where the PC re- 

60 quests the restoration of one or more files, 
upon receipt of a message from the PC iden- 
tifying the first file block to be restored, the 
restore routine 1 (see Figure 17 A) having 
tested for the type of restore requested 

65 (blocks 210), makes an entry in the task block 



table 144A in respect of the requ sted file- 
block and then notifies the tape-handler of the 
restore request (blocks 211,212). 
On receipt of a restore request message 

70 from the restore task, the tape handler first 
checks whether the message is a true request 
or merely one containing EOD/EOT information 
(blocks 213 of Figure 15). The tape-handler in 
response to receiving a file-block restore re- 

75 quest, makes an appropriate entry in its block 
table 144B and also updates the user list 145 
regarding the number of blocks to be restored 
(block 214); however, block restoration does 
not take place immediately. 

80 The process of receiving file-block restore 
requests and logging them continues in the 
above manner until all such requests from the 
requesting PC has been received. In due 
course, the PC will send an EOD message 

85 which will be passed by the restore routine 1 
to the tape-handler (see block 215 in Figure 
17 A). On receipt of an EOD indication in a 
restore request message, the tape-handler 
changes the status of the user PC in the user 

90 status list 145 from "active" to "complete" 
(block 216). The tape-handler then proceeds 
to read off the required blocks from the tape 
back to the requesting PC (block 217). This 
process involves the tape-handler referring to 

95 the block table 144B to identify each block to 
be restored and its location on the tape, this 
information having been passed up to the cen- 
tral station from the requesting PC. In order to 
facilitate this process the entries in the block 
100 table 144B are linked in the order in which 
the fileblocks appear on the tape, this linking 
being carried out at the time each newly re- 
ceived block is entered into the block table. 
As each block is read off the tape and 
105 passed to the restore task, the , block table 

144B and blocks outstanding information con- 
tained in the corresponding user list entry are 
updated. 

Each file-block-containing message received 

110 by the restore task from the tape-handler is 
forwarded with an acknowledgement to the 
requesting PC (blocks 218, 219 Figure 17B). 
In addition, the restore task updates the block 
table 144 A by removing the entry correspond- 

115 ing to the file block passed back to the PC 
(block 220). 

After all the requested blocks have been re- 
stored, the tape-handler passes an EOD ac- 
knowledgement message to the restore task 

120 (block 221) and the status of the user PC in 
the user status list 145 is changed from 
"complete" to "acknowledged" (block 222). 
On receipt of the EOD acknowledgement from 
the tape-handler, the restore task routine 2 

125 passes on this acknowledgement to the re- 
questing PC (block 223, Figure 17B). 

In due course, the requesting PC transmits 
an EOT message which is passed by the re- 
store-task routine 1 to the tape-handler. The 

130 latter, on receipt of the restore request mes- 
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sage containing an EOT indication, changes 
the corresponding entry in the user status list 
from "acknowledged" to "inactive", passes 
an EOT acknowledgement message to the re- 
5 store task, and resets itself into its NOP mode 
(blocks 224, 225 and 226 in Figure 15). 

On receiving the EOT acknowledgement 
from the tape-handler, the restore task for- 
wards the acknowledgement to the requestor 

10 PC and then closes the link and checks out in 
the manner previously described. 

In the case where the requesting PC re- 
quests restoration of the last-stored backup 
directory, the restore-task routine 1, on detec- 

15 tion of such a request, asks the tape-handler 
to forward it the backup directory (block 227 
of Figure 17 A). On receipt of this request the 
tape-handler, reads off the backup directory 
information from the disc device 13 and for- 

20 wards it to the restore task which, in turn, 
forwards it to the requesting PC together with 
an acknowledgement of the request (block 
228). Thereafter, the requesting PC transmits 
an EOT message which is forwarded by the 

25 restore task in a restore request message to 
the tapehandler to be dealt with in the manner 
explained above. 

It is convenient to arrange for backup-direc- 
tory restore requests to queue jump the nor- 

30 mal operation of the server program. This can 
be readily achieved by arranging for the sche- 
duler process always to allow such requests. 
In addition, it would be necessary to arrange 
for the tape handler not to reset its mode 

35 upon receiving an access request for directory 
restore or upon an EOT indication being re- 
ceived at the end of processing such a re- 
quest. With these modifications, a backup-di- 
rectory restore request could be processed 

40 alongside any other type of request. 

It will be appreciated that the above-de- 
scribed algorithms have been simplified in cer- 
tain respects to aid the clarity of the descrip- 
tion. In particular, the various error condition 

45 traps that would normally be included in such 
algorithms have not been specificially dis- 
closed as suitable implementations of such 
traps will be readily apparent to persons 
versed in good programming practice. 

50 Furthermore, many variations are possible 
from the disclosed algorithms without loss of 
the benefits of the present invention. Thus, 
for example, instead of the tape handler in its 
restore mode waiting until all desired files 

55 have been requested before initiating file re- 
store, each file block could be restored imme- 
diately following receipt of the restore request 
by the tape handler. Such an arrangement 
would only be practical, however, where the 

60 requester program carried out an initial sort of 
the files required so as to transmit file-block 
restore requests in the order that the file 
blocks appear on the tape media. 

In another possible variation, the scheduler 



of requests that it cannot immediately grant; 
this queue is in time order of request receipt 
except that restore requests are placed above 
backup requests. Instead of a refused re- 
70 quester PC being asked by the scheduler to 
try again after 15 minutes without any priority 
as compared to a first time requester, the 
scheduler now returns to the requester PC a 
delay time calculated to be the time after 
75 which the scheduler can grant its request tak- 
ing into account its position in the queue and 
the types of tasks in front of it. If upon retry- 
ing, a PC's request still cannot be granted, it 
retains its position in the queue and a new 
80 estimate of when the server will be free is 
returned to the requesting PC. 

Again, whereas in the described embodi- 
ment, the transmission of data (file or direc- 
tory) takes place separately from EOD or EOT 
85 indications, such indications can, in fact, be 
included in data-transmitting messages pro- 
vided that the indication is not acted upon 
until the transmitted data has been appropri- 
ately handled. 
90 The above-described backup and restore ar- 
rangement only backs up file versions not pre- 
viously backed up. For various reasons, it may 
be desirable to provide a user with the option 
to backup a file version already backed up on 
95 a previous occasion. In this case, in order to 
distinguish between the two otherwise identi- 
cal backups of the same file, the file version 
information stored in the versions list of the 
backup directory, must be expanded to include 

100 a backup time and date stamp; this stamp is 
then presented to the user whenever he se- 
lects the "display versions" option of the re- 
store user-selection menu (see Figure 4), 
In the described backup and restore ar- 

105 . rangement it has been assumed that all 

backed-up file data is stored on a single tape 
media. Where large volumes of data are to be 
backed up, provision can be made for using 
multiple tape volumes arranged in one or more 

110 volume sets. Various strategies are possible 
for using and accessing the tape volumes. 
Thus, for example, it is convenient normally to 
have on-line a particular empty or only par- 
tially-full tape volume to which all backups can 

115 be made regardless of their originating PC; 
this tape volume would only be replaced 
either temporarily when carrying out a restore 
from an earlier tape volume, or when the tape 
volume becomes full. It is of course, neces- 

120 sary for the tape location information held in 
the block map list of a PC's backup directory, 
to identify uniquely the tape volume holding 
each fileblock. During a restore operation, 
each tape volume containing relevant file 

125 blocks is called up in turn and all fileblocks of 
interest are read off before another volume is 
mounted; this orderly retrieval of fileblocks is 
achieved by appropriately linking the entries in 
the block table 144. The actual changeover 
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effected by a central-station operator in re- 
sponse to an appropriate prompt generated by 
the tape-handler process. 
To facilitate future usage of tape volumes, it 
5 is convenient to arrange the volumes in sets 
and to store on one volume of each set, the 
backup directories of all the PCs. These bac- 
kup directories are arranged to be read off 
from the disc device 13 to a pre-designated 
10 area of the tape volume when the last volume 
of the volume set becomes full. 

CLAIMS 

1 . A file selection method for selecting a 
1 5 group of files from a tree-structured file direc- 
tory stored on a computer, the computer hav- 
ing display means and user-operable, input 
means for enabling the user to identify to the 
computer items of interest displayed on the 
20 display means; said method involving: 

a) — the presentation to the user of the di- 
rectory contents by means of said display 
means, 

b) — the user selection via said input means 
25 of files of interest to be selected or dese- 
lected, this user selection process being such 
as to permit the individual selection and dese- 
lection of both sub-directories and files, 

c) — the generation and storage by the com- 
30 puter in response to the operation of the input 

means, of selection data. 

indicative of the selection statuses of the 
directory files and sub-directories, the selec- 
tion/deselection of a sub-directory by the user 

35 being interpreted by the computer as the se- 
lection/deselection of all files entered therein 
and in any sub-directories except for files 
where a contrary, lower-level, file or sub-direc- 
tory selection/deselection has been input by 

40 the user and stored by the computer in said 
selection data, and 

d) — the visual feedback to the user via said 
display means of the current selection status 
of each displayed file and sub-directory. 

45 2. A file selection method according to 
claim 1, wherein said selection data is stored 
in the form of a two-part list the first part of 
which is a list of directories individually selec- 
ted/deselected by the user together, with an 

50 indication of their selection statuses and the 
second part of which is a list of files individu- 
ally selected/deselected by the user together 
with an indication of their selection statuses. 

3. A file selection method according to 
55 claim 2, wherein the computer utilises said 

selection list to identify the selected files mak- 
ing up said group of files by examining entry- 
by-entry the said tree-structured file directory, 
or the selected sub-directories thereof, and 
60 checking the selection status of each file en- 
tered therein by reference to said selection 
list. 

4. A file backup/restore method for backing 
up files from an independently-operable per- 

65 sonal computer to a central, station and restor- 



ing files from the central station to the per- 
sonal computer, said method being applicable 
to a personal computer operating under a file- 
based operating system which maintains a 

70 tree-structured directory of files stored in a 
non-volatile storage area associated with the 
personal computer, the file backup/restore 
method including the user selection from said 
operating system directory of files for backup, 

75 this selection being effected in accordance 
with the file selection method of any one of 
claims 1 to 3. 

5. A file backup/restore method for backing 
up files from an independently-operable per- 

80 sonal computer to a central station and for 
restoring files from the central station to the 
personal computer, said method being appli- 
cable to a personal computer operating under 
a file-based operating system which maintains 

85 a tree-structured directory of files stored in a 
non-volatile storage area associated with the 
personal computer, the file backup/restore 
method involving during the backing up of 
files the generation of a tree-structured backup 

90 directory of all files backed up from the per- 
sonal computer and the file backup/restore 
method further including the user selection 
from the backup directory of files for restore, 
this selection being effected in accordance 

95 with the file selection method of any one of 
claims 1 to 3. 

6. A file backup/restore method according 
to claim 5, wherein the backup directory is 
periodically checked against the operating sys- 

100 tern directory and any files present in the for- 
mer but not in the latter are marked as non 
current, the file selection method for selecting 
files for restore being such that files marked 
as non current will only be taken to be se- 

105 lected by the computer if individually selected 
by the user. 

7. A file backup/restore method according 
to claim 5, wherein the backup directory in- 
cludes version data enabling different versions 

1 10 of the same file to be distinguished, said file 
selection method being such that in displaying 
the contents of the backup directory to the 
user for selection, only one display entry is 
presented for each file regardless of how 

1 15 many versions of that file are recorded in the 
backup directory, the file selection method 
providing the user with the option to display 
the backup directory entries relating to all ver- 
sions of a particular file, said option permitting 

120 the user to select a desired version of the file 
for restore. 
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